home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1129 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. From: "Kevin O'Donovan" <abaddon@nasoftwr.demon.co.uk>
  2. Subject: Re: Gem List
  3. Date: Fri, 29 Jul 1994 11:27:59 +0100 (BST)
  4. In-Reply-To: <23940728213132/0006795560PK2EM@mcimail.com> from "Daniel J. Hollis" at Jul 28, 94 04:31:00 pm
  5. Precedence: bulk
  6.  
  7. Daniel J. Hollis said:
  8.   > I don't think you have ANY idea of what you're talking about.  I
  9.   > am in no way "misusing" AES.  How could I *hint* at misusing a
  10.   > standard when I'm using all of the standard calls the same way
  11.   > that they are documented in the documentation, and in BOOKS?
  12.   > 
  13. I'm simply saying that its very difficult to make the AES lose keystrokes
  14. if you're doing things properly. I did a few tests last night in which I
  15. had the computer go away and do some heavy processing between key responses
  16. and I was unable to make it miss a key. The only time I did have similar
  17. problems was way back when I was half way through upgrading an application
  18. from Tos to Gem, and I mixed Gemdos console input with AES input - it worked
  19. Okay if I could be certain they never overlapped, but if they did characters
  20. would go missing (note that I'm not advocating the above - I needed to release
  21. an upgrade quickly and this was intended purely as a stopgap measure.
  22.  
  23.   > one thing, you said that you were writing another program that included the
  24.   > source from XView, which means that you didn't write it, so this book does
  25.   > not document YOUR program.
  26. We're talking about libraries aren't we? I'm writing a library that provides
  27. the Xview API (though the widgets it generates look like Motif, but WTF) along
  28. with its functionallity. I've also released a few programs, the last 3 (soon
  29. to become 4) of which use the library. The book doesn't document these
  30. programs, but because I've implemented the library described in the book it
  31. does document my library. In any case, my remark was a tongue in cheek one,
  32. meant to illustrate the ridiculousness of these "trying to go one better
  33. than the person before" type conversations. Guess I failed.
  34.  
  35.   > No one would buy any more Atari books anyway.
  36.   >
  37. People would probably buy them, but getting someone to publish them, and
  38. someone else to stock them would be a bit more difficult.
  39.  
  40.   > I never said these were not absolutes.  If we were to put
  41.   > everything on the earth that everyone else liked and wanted to see
  42.   > in a library, we would have a GUI the size of a gigabyte!  We JUST
  43.   > can't include every idea that everyone will come up with in one
  44.   > single library.  There's just no way.
  45. >From my experience of a variety of windowing systems and window managers there
  46. are not that many of these sort of options. And remember, the size of the
  47. library itself doesn't matter - a program will only be that big if it
  48. uses everything in the library, or if the library was put together badly.
  49.  
  50. Kev
  51.  
  52. -- 
  53. Kevin O'Donovan
  54. abaddon@nasoftwr.demon.co.uk
  55. kebab@cix.compulink.co.uk
  56.  
  57. Taste me, taste me--I'm organic
  58.  
  59.